과제의 핵심취지

배포링크

• https://chen4023.github.io/front_7th_chapter3-2/basic/

• https://chen4023.github.io/front_7th_chapter3-2/advanced/

• React의 hook 이해하기

• 함수형 프로그래밍에 대한 이해

• 액션과 순수함수의 분리

과제에서 꼭 알아가길 바라는 점

• 엔티티를 다루는 상태와 그렇지 않은 상태 - cart, isCartFull vs isShowPopup
• 엔티티를 다루는 컴포넌트와 훅 - CartItemView, useCart(), useProduct()
• 엔티티를 다루지 않는 컴포넌트와 훅 - Button, useRoute, useEvent 등
• 엔티티를 다루는 함수와 그렇지 않은 함수 - calculateCartTotal(cart) vs capaitalize(str)

기본과제

• Component에서 비즈니스 로직을 분리하기

• 비즈니스 로직에서 특정 엔티티만 다루는 계산을 분리하기

• 뷰데이터와 엔티티데이터의 분리에 대한 이해

• entities -> features -> UI 계층에 대한 이해

• Component에서 사용되는 Data가 아닌 로직들은 hook으로 옮겨졌나요?

• 주어진 hook의 책임에 맞도록 코드가 분리가 되었나요?

• 계산함수는 순수함수로 작성이 되었나요?

• Component에서 사용되는 Data가 아닌 로직들은 hook으로 옮겨졌나요?

• 주어진 hook의 책임에 맞도록 코드가 분리가 되었나요?

• 계산함수는 순수함수로 작성이 되었나요?

• 특정 Entitiy만 다루는 함수는 분리되어 있나요?

• 특정 Entitiy만 다루는 Component와 UI를 다루는 Component는 분리되어 있나요?

• 데이터 흐름에 맞는 계층구조를 이루고 의존성이 맞게 작성이 되었나요?

심화과제

• 이번 심화과제는 Context나 Jotai를 사용해서 Props drilling을 없애는 것입니다.

• 어떤 props는 남겨야 하는지, 어떤 props는 제거해야 하는지에 대한 기준을 세워보세요.

• Context나 Jotai를 사용하여 상태를 관리하는 방법을 익히고, 이를 통해 컴포넌트 간의 데이터 전달을 효율적으로 처리할 수 있습니다.

• Context나 Jotai를 사용해서 전역상태관리를 구축했나요?

• 전역상태관리를 통해 domain custom hook을 적절하게 리팩토링 했나요?

• 도메인 컴포넌트에 도메인 props는 남기고 props drilling을 유발하는 불필요한 props는 잘 제거했나요?

• 전체적으로 분리와 재조립이 더 수월해진 결합도가 낮아진 코드가 되었나요?

과제 셀프회고

먼저 과제를 진행하면서, 리팩토링 관점에서 함수형 프로그래밍의 관점으로 새로운 접근을 해볼 수 있어서 새로웠습니다.
데이터, 계산, 액션 관점으로 코드를 이해하고, 분리된 영역을 데이터 -> 순수함수 -> 액션의 흐름으로 분리하여
조합하여 사용할 수 있구나를 꺠달을 수 있었습니다.

이번 과제에서 큰 범위에서는 shop / admin으로 나누고 내부적으로는 cart, product, coupon의 범위로 나누어서 접근했습니다.

사실 처음에는 fsd를 활용하여 각 관심사 별로 로직과 UI를 함께 관리하는 방식으로 접근했었는데,
구현하면서도 이번 과제의 규모에서 fsd를 사용해보는게 의미가 있을까? 의문이 들던 찰나에 Q&A 세션에서
"다음주가 FSD 과제이니, 불편함을 경험해보세요."라고 하셔서 기존 폴더구조를 기반으로 진행하게 되었습니다.

component 폴더 내부에 관심사 별로 컴포넌트를 분리하여 관리하였습니다.

src/basic/
├── App.tsx              # 59 라인 - 조합만 담당
├── main.tsx
├── index.css
├── types.ts             # 타입 정의
│
├── components/          # UI 컴포넌트 내부에서 도메인 별로 컴포넌트 분리
│   ├── CartPage.tsx
│   ├── icons/
│   └── ui/
│       ├── admin/       # 관리자 페이지 컴포넌트
│       │   ├── AdminHeader.tsx
│       │   ├── AdminPage.tsx
│       │   ├── AdminTabs.tsx
│       │   ├── coupon/
│       │   │   ├── AddCouponCard.tsx
│       │   │   ├── CouponCard.tsx
│       │   │   ├── CouponForm.tsx
│       │   │   ├── CouponSection.tsx
│       │   │   └── CouponTable.tsx
│       │   └── product/
│       │       ├── ProductForm.tsx
│       │       ├── ProductSection.tsx
│       │       └── ProductTable.tsx
│       ├── common/      # 공통 UI 컴포넌트
│       │   ├── badge.tsx
│       │   ├── button.tsx
│       │   ├── card.tsx
│       │   ├── input.tsx
│       │   ├── label.tsx
│       │   ├── NotificationList.tsx
│       │   ├── select.tsx
│       │   └── table.tsx
│       ├── feature/     # 기능 컴포넌트
│       │   ├── CartButton.tsx
│       │   ├── ModeSwitchButton.tsx
│       │   └── SearchInput.tsx
│       ├── layout/      # 레이아웃 컴포넌트
│       │   ├── AdminLayout.tsx
│       │   ├── CartLayout.tsx
│       │   └── GlobalHeader.tsx
│       └── shop/
│           └── ProductCard.tsx
│
├── constants/           # 상수
│   └── index.ts
│
├── hooks/               # 커스텀 훅
│   ├── useCart.ts
│   ├── useCouponForm.ts
│   ├── useCoupons.ts
│   ├── useNotifications.ts
│   ├── useProductForm.ts
│   └── useProducts.ts
│
├── models/              # 비즈니스 로직 (순수 함수)
│   ├── cart.ts
│   ├── coupon.ts
│   ├── discount.ts
│   └── product.ts
│
├── utils/               # 유틸리티
│   ├── formatters.ts
│   ├── validators.ts
│   └── hooks/
│       ├── useDebounce.ts
│       ├── useLocalStorage.ts
│       └── useValidate.ts
│
└── lib/
    └── utils.ts

폴더 별 힌트의 의미

• model : 모델 폴더 내부에는 해당 관심사의 순수함수를 구현한다. (ex. 장바구니 아이템 수 계산, 훅을 관리하기 위한 계산 로직 등)
• hooks : 훅에는 관심사 별로 구현한 순수함수를 기반으로 액션을 작성한다 . (ex. 카드에 상품 담기, 쿠폰 추가하기, model 내부 함수를 활용하여 액션 구현)
• pages : 훅에 있는 액션을 기반으로 액션 별 핸들러를 등록하여, 비지니스 로직이 UI 관점에서 분리되어 관리될 수 있도록 함

과제를 하면서 내가 알게된 점, 좋았던 점은 무엇인가요?

커스텀 훅 설계

훅 목록 및 역할

훅 간 의존성

useNotifications (독립)
       │
       ▼ onNotify
┌──────┴──────┐
│             │
▼             ▼
useProducts   useCoupons
      │
      ▼ products
useCart ───────────────► cartModel (순수 함수)

이번 과제에서 내가 제일 신경 쓴 부분은 무엇인가요?

액션에서 계산을 분리해보기로 처음 과제를 접근했던 것 같다.
함수형 프로그래밍에서는 순수함수와 부수효과에 대해 정의하는데, "부수효과를 멀리하고 순수함수를 합성해서 프로그래밍해라" 라고 설명하고 있다.

근데 흔히 기능을 개발하다보면, 부수효과를 멀리할 수 있는 기능은 거의 없다고 생각한다.
서버에서 받아오는 데이터를 기반으로 UI를 구성하는 일이 대부분이고,
로그를 남기고 파일을 읽는 경우가 많다. 그렇게되면 순수함수로만 서비스를 개발할 수 있는가? 불가능하다.

내가 접근한 관점은 아래와 같다.

• 데이터 : 이벤트에 대한 사실
• 액션(hook) : 실행 시점이나 횟수에 의존하는 경우 (버튼을 1번 클릭했을 떄와, 100번 클릭했을 때 다른 결과가 반환됨)
• 계산(model) : 입력값을 통해 출력값을 만들어내는 것 (같은 입력이 들어왔다면 1번 실행했을 떄와 100번 클릭했을 때 동일한 결과가 나와야함)

• 액션이 발생하면 미리 정의된 계산에 의해 데이터가 바뀌게 된다.
  이번 과제에서 사실 계산함수와 액션을 명확하게 구분했는가? 하면 자신있게 네 라고 대답할 수는 없을 것 같다.

model 내부에서 addCart,updateCart와 같은 로직을 작성하고, 이 로직을 기반으로 hooks을 설계하고, 실제 사용 컴포넌트들에서는 인자만 내려줄 수 있게 구현했는데, 순수 계산 로직이 아닌 액션 로직은 아예 훅에서 관리하는게 맞았을지도 모르겠다는 생각이 든다.

전역 상태 관리

• advanced 아키텍쳐

┌─────────────────────────────────────────┐
│            COMPONENTS (UI)              │
│   App, CartPage, AdminPage              │
└─────────────────┬───────────────────────┘
                  │ 호출
                  ▼
┌─────────────────────────────────────────┐
│         HOOKS (조합 레이어)              │
│   useCart, useProducts, useCoupons      │
└────────┬────────────────────┬───────────┘
         │                    │
    상태 읽기/쓰기             로직 위임
         │                    │
         ▼                    ▼
┌─────────────────┐   ┌─────────────────┐
│  STORE (Atoms)  │   │ MODELS (순수함수)│
│  cartItemsAtom  │   │ cart.addItem    │
│  productsAtom   │   │ discount.calc   │
│  couponsAtom    │   │ coupon.apply    │
└─────────────────┘   └─────────────────┘
         │
         ▼
┌─────────────────┐
│ TYPES/CONSTANTS │
└─────────────────┘

• 심화 과제를 하면서 고민했던 건, 이 상태를 꼭 전역으로 관리해야하는가?였다.
• 알림이나 모달 등등 기본적으로 루트에서 사용되어야 하는 요소들은 전역으로 관리하는게 익숙하지만, product, coupon등 평소였다면 백엔드한테 받아서 관리했을 데이터들이었기에 고민했던 것 같다.

내가 전역 상태로 관리한 상태는 다음과 같다.

• product : admin, cart 동시에 사용되기 때문에 전역으로 관리
• coupon : admin, cart 동시에 사용되기 때문에 전역으로 관리
• notification : 전역 관리
• cart : 장바구니 상태는 쿠폰 적용이나, 가격 계산시에 상태 쓰기가 필요했기때문에 전역으로 관리

고민했던 요소 : searchValue

• 검색어는 헤더에서 적용되고 있기 때문에, 검색어를 기반으로 상품 리스트를 필터링 해야한다.
• 그렇게 되면 cartPage, header 두가지에서 사용된다는 것인데, 나는 layout으로 admin/cart Header를 분리하여 관리하고 있었기때문에, 그냥 layout에서 관리하면 되는거 아닐까? 생각이 들어서 그냥 layout에서 상태 선언하고 각각 컴포넌트에 내려주는 방식으로 진행했다.
  궁금했던 점은 물론 전역상태를 사용했다면, 필요한 곳에서 각각 뽑아와서 호출할 수 있었겠지만, 2개 이상에서 사용되기 때문에 꼭 전역상태로 관리하는게 좋은 방식일지 의문이 들었다.

클로드가 알려준 전역상태 관리 기준은 다음과 같았다.

전역 상태 판단 기준

• 트리상 거리가 3단계 이상 떨어져 있나?
• 상태 생명주기가 특정 페이지/레이아웃을 넘어서나?
• 여러 곳에서 동시에 읽고 쓰나?
• 앱 어디서든 접근 가능해야 하나?

사실 이 기준을 생각했을 떄, 검색어는 헤더 하나에서만 쓰기가 가능하고, 나머지 하위 컴포넌트들은 검색어를 읽기만 할 뿐이다. 그래서 그냥 레이아웃에서 검색어를 관리하고 내려주는 방식을 채택했다.

그리고 이번 과제를 하면서 느낀점은 AI는 리팩토링을 진짜 못하는 것 같다.
내가 하나하나 방향을 제시해줘야, 그나마 알아듣는 것 같다..
(리팩토링 해달라니까 필요없는 함수를 너무많이 생성해놔서 추후에 다 검토했다 ㅠ)

이번 과제를 통해 앞으로 해보고 싶은게 있다면 알려주세요!

리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문 편하게 남겨주세요 :)

• 코치님은 평소에 어떤 방향으로 리팩토링을 설계해나가시는지 궁금합니다.

• 이번 과제에서 searchValue는 layout에서 관리하는 방식으로 사용하고 전역으로 설계하지 않았습니다. 코치님은 전역상태에 대한 판단 근거를 어떤 방향으로 잡아가시는지 궁금합니다.

• 현재 model 내부에서 add, delete 관련 액션을 다 선언하고 hooks에서는 model 내부 로직을 활용하여 결과를 기반으로 전역 상태를 업데이트하고 알림을 관리하는 방식으로 설계되어있습니다.(액션의 흐름만 읽힐 수 있도록)
  코치님이 의도하신 방향은 순수 계산 로직만 model로 관리하고, hooks에서는 순수 계산함수만 사용하고, 이 외 add, delete와 같은 액션 로직은 전부 hooks에서 관리할 수 있도록 하는 방향이었던 것 같다고 생각합니다. 혹시 제가 이해한 방향이 맞을까요?

• 현재 구조가 atom을 선언하고 이를 기반으로 hooks에서 로직을 관리하는 방식으로 진행했습니다.
  만약에 zustand를 사용하였다면 store 기반으로 내부에 액션을 같이 관리했을 것 같은데,
  jotai로 진행한 방식에서는 이 접근 방식이 맞았을지 궁금합니다.
  사실 atom 내부에서 관리한다고 해도, 사용하는 곳이 많지 않은 액션이 많아서, 이미 훅에 정의되어있는 로직에 전역 상태를 적용하고 전역상태 도입 전과 동일하게 사용하는 곳에서는 훅을 호출하는 방식으로 진행했습니다.

jotai를 사용하여 hook로직을 간소화하고, atom내부에서 전역으로 로직을 관리하는 방법이 더 좋은 방향이었을까요?
사실 심화과제 요구사항에 zustand를 언급 안하신 이유가 있으신지도 궁금합니다!